perm filename LETTER.ALL[P,JRA] blob
sn#134868 filedate 1974-12-05 generic text, type C, neo UTF8
COMMENT ā VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 \\M1BASL30\M2BASB30\M3NGR25\M4NGR20\M5BASI30\M6BUCK75\F1
C00015 ENDMK
Cā;
\\M1BASL30;\M2BASB30;\M3NGR25;\M4NGR20;\M5BASI30;\M6BUCK75;\F1
\F6\CCIS 280
\F1
\Cas envisioned by
\CJohn Allen, Research Associate
\CStanford University Artificial Intelligence Labs.
\J
I will be teaching the CIS280 (data structures) course in the spring
semester. It will be a non-standard approach to the subject, but one
which has proven to be quite successful and exciting.
Let me give you an introduction to the course. It grew out
of a similar course on data structures I developed at UCLA
while teaching as an Assistant Professor in 1970-1972.
Many universities, UCLA included, present data-structure courses in their
program
at a point when the typical student has no background for assessing
the importance of the techniques. Typically a book like Knuth's is
used. The difficulty is that a background in simple PL/1 or Fortran programming
offers no motivation for studying trees, hashing, garbage collection,
stacks, threading, or any of the other esoteric tricks. My contention is that
the ideas which motivate the techniques, present themselves very naturally in the
context of LISP and its implementation.
My second objection is the use of machine language for discussion
data-structure algorithms. We don't require machine language for numerical
analysis, so why not treat non-numerical algorithms with the same respect?
LISP is a natural language for such discussions; it not a toy language, but
has a rich history of interesting programming examples.
Once motivation for the study and understanding of data structures is
established, then the techniques can be introduced easily in the
context of implementation of LISP. Indeed, many of the current tricks
of software implementation originated in LISP's implementation.
But even at this point the appropriate level of abstractness
should be used. All of the data-structure techniques are best understood
at a level higher than machine language. When you want to implement a
specific technique on a specific machine, then talk about efficiency
and bit-pushing.
Thus I believe that such a course should make clear the distinction
between ideas, and techniques or tricks.
I taught five variants of this course at UCLA, each becoming more LISP
and less Knuth. The material has been revised and embellished
during the last two years,
and has been taught both years at the UC Santa Cruz graduate workshop.
The course will attempt to be self-contained because I think LISP
is the best way to introduce prospective students to the field and
fewer preconceptions about programming languages, the better.
LISP is an excellent way to take intelligent, but technically naive,
students rapidly to advanced topics in such a way that intuition and the
continuity of Computer Science is maintained.
Thus
the course goes from very basic undergraduate material to current
research in semantics.
Basically the material falls into 6 areas:
\F21.\F1 The mechanics of the
language; recursion, functional arguments. Representation of
algorithms in a programming language, representation of domains as
data structures.
\F22.\F1 Evaluation; the importance of interpretation and
its relation to denotational models.
\F23.\F1 Implementation of the static structure of LISP and the
problems of machine orgainzation. Symbol tables, hashing,
linked allocation, garbage collection, and storage management.
\F24.\F1 The dynamic structure of LISP and compilers for LISP; LISP, being
a very clean way to introduce compilation. One-pass assemblers, fix-ups,
debugging and programming environments.
\F25.\F1 Storage and efficiency; more detailed discussion of storage
management; arrays, strings, stacks. Tricks of LISP programming.
Efficiency: double linking, threading, fancy garbage collection....
\F26.\F1 Implications for
language design; given a clear understanding of LISP, what can be
done better? Most of this comes from my own ideas on a LISP-like language
with user-defined data structures and a semantics which is more
amenable to proofs and verifications.
Besides my own ideas, this section will incorporate other more well-known
"extensions" of LISP ideas. Namely the two innovations deriving from PLANNER:
pattern directed invocation, and structured data bases.
LISP is the most most poorly
understood programming language around, and it gets a little tiresome
to see people re-inventing McCarthy's ideas simply because there's no
decent documentation.
There's a succinct statement by Strachey which
reflects my attitude about programming languages and the approach
advocated in the course:
\F5"I
always worked on programming languages because it seems to me until
you could understand those, you couldn't understand computers.
Understanding them doesn't really mean only being able to use them. A
lot of people can use them without understanding them."\F1. This quote
appears at the beginning of the chapter on evaluation!
Prequisites? That's hard to say. Interest and an ability to work very
hard are the main requirements.
Now to more mundane details: the Bookstore will be printing copies of the
current manuscript very shortly. There are currently 26 students enrolled.
(After reading this there may be a sudden decrease, but ...).
If the interest exceeds the supply, then people are bound to get
upset. Also the cost per unit is dependent on the total number of copies
printed.
So if you know of people who might be interested in attending this class and/or
purchasing the
notes, they should register your intention immediately.
\.
John Allen